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Mail Stop Amendment 
Commissioner for Patents 
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Alexandria. VA 22313-1450 

DearSir 

We, Melur K. Raghuraman and Venkataraman Ramanthan, hereby declare the following: 

1 . We are the original, joint mventors of die subject matter claimed and disclosed in 
the above-captioned ^jplication. 

2. We have been informed that the above-captioned apphcation, U.S. Application 
Serial No. 09/490,981 was filed January 24, 2000 ("the AppHcation"). 

3. We submit this Declaration for the purpose of providing evidence that the subject 
matter claimed in the ApplicaHon was conceived and reduced to piactice in the United States of 
America as of a date prior in time to February 12, 1999. 



4. We have also been infoimed that Spasojevic, U.S. Patent 6.269,410 (hereinafter, 
"Spasqjevic;" a copy of which is attached hereto as Exhibit "A") was cited against the claims 
pending in the Applicatioit 

5. We have been infonned that the effective date of Spasojevic as an alleged prior 
art reference is Febniaiy 12, 1999. 

6. We have read and understood Spasojevic. attached as Exhibit A, 

7. To establish the conception date of our invention prior to February 12, 1999, we 
provide evidence in the form of an article we authored entitled •'Network Perfonnance 
Monitoring in Windows NT (hereinafter, "the article;" a copy of which is attached hereto as 
Exhibit "B") which describes fects relating to each and every element of claims 4-6, 10, 15, 17, 
andl8asrequiredbyM.P.E.P.7l5.07tosatisfy37CF.R.§ 1.131. Hie article describes the 
invention of the above-noted patent application, and specifically inchides a description of a 
method for tracing both transmission and receipt of data within a computer network to fecUitate 
network monitoring. In particular, the article describes a method of tracing a transmission of 
data over a computer networic comprising: detecting a tnuisport-Iayer request 

input/output packet; searching the input/output packet to detennine an identity of a process that 
created the input/output packet; and storing in a trace log an entry representing the request, ' 
wherdn the entry comprises the identity of the process, and wherein the trace log is accessible to 
determine a volume of data being transmitted over the network. 

8. To establish a date of actual reduction to practice of our invention prior to 
February 12, 1W9, we provide a sample ofour invention's output in the fonn of a kernel trace 
fragment fiom a TCP Send test, translated into readable text format, as presented in Appendix A 
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of our article and originally obtained using the Method of Tracing Data Traffic on a Networic. 
The article describes this output m relation to the tracing method presented by both Ae article 
and the present application. Particulariy, Ae article's "Analysis of sample Traces" section 
associates all essential elements of ourprraent application to the sample ou^t First, the article 
describes detecting a tran^rt-layer request to transmit an input/output packet as flie ^jpearance 
of TCP Send events. Second, Ae output analysis explains searching the iq)ut/ou^ut packet to 
determine the identity of a process that created the input/output packet by presenting bo A the 
source IP address/^ and destination IP addresa^rt Finally, the article illustrates storing in a 
trace log an entry representing Ae request, wherein the entry conqjrises the identity of the 
process by explaining that the •Reprocess ID.. .[is] saved when the connection was created 
[and] is.. . recorded with every send event" By completing these three steps, which resulted hi 
the output presented and described by the article, we conchided, prior to Febniary 12, 1999, that 
the network traffic can be properly charged to processes fix>m the trace, thereby satisfying the 
object of the present application as evidence of achial reduction to practice. 

9. To further establish evidence of actu^ reduction to practice prior to F^vuaiy 1 2, 
1999, the article describes additional elements of our present application in the "Event Tracing 
Sends / Receives" section. This section of die article describes all elements of our invention 
inchiding detecting an acknowledgement of the transmission and storing in the trace log an entry 
representing the completion of the transmission. Particularly, this portion of the article proposes 
tracing a receipt of data from a computer networic comprising: detectmg a transport-layer request 
to transmit a packet for an input/output connection to a port; searching the packet to determine an 
identity of a process that created the packet; and in response to the detection of a receipt of data 
at the port, storing in a trace log an entry representing the receipt of the data, wherein the entry 



comprises the process identificatioii, and wherem the trace log is accessible to determine a 
volume of the data being transmitted over the network, 

10. Similarly, the "Event Tracing Sends / Receives" section along with other portions 
of the article describe a fecility for tracing data traffic on a netwoilc at the transport layer, the 
facility comprising: an identifying means for identifying a process causing a Iransport^layer 
request to transmit data via the network; and a logging means in communication with the 
identifying means for logging an event, wherein the event comprises the identification of the 
process and wherein the logging means is useable to determine a vohime of data traveling over 
the network. 

11. The article fiirther describes a computer-readable medium having stored thereon 
computer-executable instructions for performing steps comprising: detecting a transport-layer 
request to transmit an input/output packet; searehing the mput/output packet to determine an 
identity of a process that cre^ed the input/output packet; andstoring in a trace log an entry 
representing the request, wherein the entry comprises the identify of the process, and wherein die 
trace log is accessible to detetinine a volume of data being transmitted over die network. The 
article also teaches the additional step of detecting an acknowledgment, storing in die trace log ' 
an entiy representing die completion of the transmission. 

12. Finally, the article explains a computer-readable medium having stored thereon 
computer-executable instructions for performing die steps comprising: detecting a transport-layer 
request to transmit a packet for an input-output connection to a port; searching die packet to 
determine an identity of a process diat created die packet; and in response to die detection of a 
receipt of data at die port, storing in a tiace log an entry representing die receipt of die data. 



■4- 



wherein the enliy comprises process identification, and wherein the trace log is accessible to 
detennine the volume of the data being transmitted over network. 

13. We wrote the article in the United States of America, where our invention was 
also conceived, prior to Februaiy 12, 1999. We support this assertion with the attached Exhibit 
"C showuig that we presented the findmgs of this article on December 8, 1998 in Anaheim, 
California, U.SA., as part of the International Computer Measurement Group Conference. 

14. All statements made herem of our own knowledge are true and all statements 
made on information and belief are believed to be true; and further these statements were made 
with the knowledge that willfiil &lse statements and the like so made are punishable by fme » 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and such 
willful false statements may jeopardize the validity of the application or patent issued thereon. 
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Abstract 

Most eapaeifypUJining ^orufar networks have treated the system as a source getarator and focused on 
Jrern^ amnts and frame fytes by listening to the wire. Some have employed smart ways t^identms the 
tvpltcobon respons&lefor network traffic by scanning the packet headers. These methods are en^Ae 
ana arbitrary. In this pt^. we present trace Instnanentation t^the TCP/IP stack In Windows NT that 
prawba key irfymion far ct^iiy planners far correctly charging network traffic to the individuci 
services €tna explications. 



Introduction 

In this cfient^server world of computing tfiat we 
live in today, capachy planning activity is just 
not limded to the saver but to the entire system 
including the clients, servers and network 
devices. In the past, netwoik capacity planners 
^'^^ *® systems without serious caocem 
and system capachy planners have in turn 
ignored the network devices in their analysis. 
One nsByK reason for this is the lack of 
appropriate performance data to tie the two 
workis and tte fear of overhead of 
instrumeatation. 

Accuracy of model ii^ metrics is often cited as 
Ac key indicator of the validity of a capacity 
analysis. In the last couple of years, there have 
beai several papers in this conf^cnce 
mentioning the lack of perfomoance data in 
MicrosoM) Windows NTiS) operating system 
mainly for Capaci^ Planning (1,2]. We 
addressed these concerns by introducing an 
Event Tracing FacOity in MTmdows NT 5.0 and 
published die event tracing API[3J in this 
confiaencc last year. White it addressed system 
data requirements adequately, data related to 
network was bcking. The purpose of diis paper 
is to describe the network instrumentation woric 
that has been done to con^lcmcnt the kernel 
trace instrumentation work for Windows NT 5.0. 

WiA internet access becoming common place 
today, there is no drop in die appetite for networic 
bandwidth for web based applications. In feet, 
high speed networking is a very ini^xntant focus 
of Windows NT 5.0 i^ch already achieves I to 
2 Gbps througlq)ut With netwoik speeds getting 
this fest, any instrumentatmn must be highly 
optimized to take minimal overhead. 



hi order to place the network instrumentation in 
die larger context of NetworidQg layers in 
Wmdows^, we devote the next section to 
describe die networking architecture in Windows 
NT. We describe die capacity plannmg data 
requirements Networks and what data is 
collected dirough die instrumentation. Sample 
trace data from our experiments are also 
presented. 

Event Tracing in Windows NTS.0 

The next version of Microsoft Wmdo«^ NT 
operatiiig system will have a uniform fiaiwwork 
for event tracing, specifically for capacity 
planning. The event tracing mechanism 
implements a circular buffer pool maintained by 
the operating system and an API set for Trace 
Providers, Ccmsumers and Management Control 
The trace toggcr can accept data from kernel 
mode device drivers and user mode applications. 
In addition to providing a fecility to log trace 
data for plications, dw Windows NT kernel 
has been instrumented to provide key capacity 
planning m^rics that were not avaDabie duou^ 
the cwnmonly used performance tool 'Perftnon'. 
The following system events are instrumented: 

1. Process CreationfDeletion event The 
ProcessId, |»rent process 14 Security Id and 
the Image File name are recorded. 

2. TVem^Oeorfon^iDe/ef/oit event The Thread 
Id and Its process Id are also recorded. 

3. Hard Page fault event The di^ signature 
and the size of die first disk read resulting 
from die page feult are also recorded. 

4. Disk Read/Write event The disk signature 
and the size of the operation are recorded. 
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Multiple logger streams may be active at one 
tune, ^ically one for ttie kemei lqgger and one 
for each of the trace^^eoabled applications 
nmning on a server. The Consumer APIset 
makes it easy to pocess the trace from multiple 
logger streams in the proper order and returned 
to the caller one event at a time. 

Networking ArchitecturB in 
Windows NT 

Networking capabOities are built into Windows 
NT and it is (vganized as layers (See Figure I). 
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Rgure 1. Windows NT Network Layers 

Windows NT netwi»king components include: 
•OTianqjort jHiotocob (DLC, NetBEUI, 
NWLink; and TCP/IP) define dse rules 
goveming ocnnmunications between two 
CGmputers. 
*0 Inter-process communicatioa GPQ 
compuuenta, such as named pipes and 
mafl slots, aUow applicsdons to 
communicate with each other over a 
netwoik. 

* □ File and Print sharing components aQow 
resources to be made availabb <m a 
netwoik. 

The Multiple uniform nammg convention (UNQ 
Provider (WUP) and Multi-Provider Router 
(MPR) make it possible to write applications diat 
use a single API to communicate using any 
netwc^ voidor's redkector. 

There are two boundary layers in the 
architecture, namely the Netwoik Driver 
Inter&ce Specification (NDIS) and Tran^>ort 
Driver Interface (TDQ. The NDIS layer jm>vides 
the interlace and a wr^jper to the Network 



Interfece Card (NIC) device drivers. The TDI 
boundary layer provides a ccHmnoa mter&ce 
specification to communicate widi various 
transport drivers. While several protoco ls m 
s upported in fee transport layer, VCWH'TSms 
the main focal point for all networking activi^. 

The protocol suite benefits from yeas of 
research and is the roost fevored smte m fee 
Internet In WindowsNT, several sermes make 
use of TCP/IP stack, niost notab^ FiM>rint 
services and Socket-based applicatioBS. Most 
services require reliable data transmisnoa and 
use TCP/IP suite for end to end reliable deliveiy. 
We will explain the File/Print services and 
Sockets in more detail in the next sectkn. 

File and Print Services 

The File and Print services are supported by two y ^ov 
services ( R ^irector and Server) tot are byerS. r r^CA" 
on top of Transport Driver Interfece lawM * 
shown in i^igure z.^ They pcwkte an 
enca{^ation over toe tiW system and network 
transparency for applications remote 
files. 

When a process on a Windows NT lystem tries 
to open a file that resides on a remote computer, 
die following steps occur . 

*QThe process calb fee I/O Manager to 

request feat die file be opened. 
* □ The I/O Manager recognizes feat the 

request is for a file on a remote 

computer, so it passes it to the redirector 

file system driver (RDR.Sys). 
*OThe rediiectcn* . passes fee request to 

lower-level network driveo that 

tran^nit it to the remote Server for 

processing. 
*□ The transport receives a send ID request 

packet (bp) for fee SMB header and 

command. 

*0 This send is translated into fianns and 
queued for dispatch on fee wire through 
fee Miniport driver. 
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Figure 2. Server and Workstation Services 

On the remote WindowsNT server system, when 
the server service receives a request firom a 
remote computer asking it to read a file that 
reskles on the hard disk, the following stq;>s 
occur 

* D The tow-level network drivers receive 

tfaerequest and pass it to the server 
driver (SRy.SYSX 

* D The server passes a file read request to 

the appoiRiate k)cal file system drivo^. 

* 0 TTie local file system driver calls lower- 

level disk device drivers to access the 
file. 

* 0 The data is passed back to die local file 

systan driver. 
^ 0 The local file system driver passes the 
data back to die server. 

* 0 The saver passes the data to the tower- 

level netwonrk drivers for transmission 
back to the client computer. 

Socket-based Applications 
Socket-based applications are supported through 
die Windows Socket Provider (WinSockX Figure 
3 ^ows die reladottship between various 
modules and TCP/IP. 

A Socket based user applicadon that would like 
to provide a service on pon P 0>re-advertised) to 
all clients wouki open vp a socket tfarougji 
WinSock tmd listen on the socket for connecdon 
requests. This would translate as an address 
object with TCB structures listening on that port 
widi the server's IP address(es) and a wOd<ard 
IP address to denote client addresses. 
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Figure XJCCPfSP Stack 

When a client requests a connection, a fiame 
comes in on one of the NICs (with the client's IP 
address and connectmg port ^ and is tied to one 
of tiiese TCB strucmres. TCP calls across TDI to 
indicate to the socket provider, i^^iidi in turn 
caUs into the User's snvice ai^lication for 
accq>tance. Once accepted, frames are received 
and sent on the hfIC mvolved m die connection. 
Though fl w physical NIC flirougfa which tf^ t » 
c dflasctlon data is routed can ch^np ? 1>^ ^' time, 
the IP addresses and port numbers don't change 

and l^H thffp^igglYa flff pnniw>f;rinn mnti^ fii^ 



The user iq)plicatkm requests a Send to the 
socket service provider wi& a pointer to the data. 
The socket provuier, namely AFD will kxk die 
pages in menxRy and request TCP across TDI to 
sebd. TCP cuts the requests to fiames and calls 
the minqrart driver COTrespcmdnig to die NIC 
through which, the data needs to be transmitted. 
The Miniport driver sends the fiames and calls to 
TCP to complete eadi fi-ame-scnd event. The 
TCP requests are |vocessed asyndffonously as a 
rule, and could happen in dw context of the 
system thread dispatched fay die socket provider 
(K- a DPC CDe&rred Procedure Call) from Ndis. 
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In the case of receive, the minipcnt driver 
. services the intern^ and dirougji Ndis, queues a 
DPC to process the fiame. This DPC identifies 
the protocol ^ack and calls the appnqpriate 
Receive Event handler. When dus diread 
executes TCP Receive routine m its context, die 
data is mdicated up or is filled m pre-posted 
receive buffers from die application. 



Event Tracing Sends / Receives 

A TCP Send needs to be traced at fte 
end of &e send. The end of a send is mailced by 
the processing of an ACK(acknowledgeniem) 
fnm die otiier connection em^xunt 
corresponding to die last- byte of the send. 
Thxou^ TDI, TCP receives an loRcquestPackct 
(IRP) from AFD with a pointer to a locked user 
buffer / locked set of pa:ges from a file's cached 
view. TCP creates a Send-Request structure, 
which caches Has IRP, splits die data into firames, 
and sends than across. When the last adc (ack 
acknowledging the last byte sent) airives, part of 
receive processing involves queuing tiie 
conresponding Send-Request for conapledcm. 
When tbe c<Hnpletion queue is processed, the 
cached IRP is completed to the upper layer. 
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F^nre 4* TCP Send 

Betweoi the initiation of the Send and tibe 
completion, several copies of the data could g^ 
transmitted due to retransmissions, or the send 
could get cancelled, in ^uch case, a aHi^>letion 
doesn't occur. In Fig 4.. the timelme of events 
during a send is explained. Since only the 
completion is traced, the use of the NIC to send 
out the said number of bytes is guaranteed. Also, 
as &r as the user application is concerned, the 
Send through Tdi completed only ^en the IRP 
is completed in the sodcet driver (^^lidi may 
wake up the btocked thread m die case of 
synchronous i/o or trigger the ap pr op r i ate event 
in the case of async i/o). 

Tracinn receives is more complex dian Sends, in 
die sense that tracmg informaticm needs to be 
generated at more points than one. In the case of 
receive, we should not care if die TCP protocol 



sends out acks or if this ts . only part of a recdve 
which got cancelled from the other end pcNUL 
The number of bytes received must be accounted 
for ex^tly. We will first take the case of a |Ke- 
posted receive and how it is traced for capacity 
planning purposes. 

In the case of prc-posted receives, TCP receives 
an IRP throu^ TDI to receive a certain size. 
TCP caches this IRP m a Receive-Request 
structure. When a chunk of a certain size of data 
is received (couki be less than the reque^ size, 
to improve latoicy) TCP completes die request 
widi the dien-avaUable number of bytes and the 
appropriate bu£fers. If more needs to be received, 
the receiver (say application dirougb socket 
interfece) posts laott receivo-IRPs which are 
complet^ as frames are received. In F^ 5., the 
receive completion and trace timing is explained. 
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Figure 5. TCP Receive 

It is possible to receive i^iea no receives are 
posted. In such cases, die data is indicated to the 
receiver as soon as the first fi:ame is received. If 
any more <tota meeds to be received, TCP 
receives a piggybacked Irp. TCP generates a CP 
trace in this indicate path to accurately account 
for the accepted number of bytes. 

Data Collection Issues 

Windows NT uses a packet oriented I/O model 
for performing I/O operations to disks as weO as 
to network devices. Whenever a uso* application 
or service posts a Send/Receive request, an IRP 
is created and sent to TCP. Typically the IRP is 
filled with the context of die thread requesting 
die operation. In die case of sends, it is possible 
to identify the correct user diread to charge die 
bandwiddi utilization. In die case of receives, a 
DPC is generated m KDIS, \^iich doesn't run in 
the context of any user thread. With respect to 
receives through the mdicate-path described 



above, when the data is accepted without 
requesting more receives toough IRPs, it b not 
possible to make a correspondence. In such 
cases however, the port infonnation that is 
provided is useful in identifying the service. 

What is Instrumented? 

K Send Complete event when a TCP send 
request is complete (when an ACK for the 
last byte of the Send Request is received). 
The source address, destination address, 
source port number, destination port 
number, bytes transmitted are also recorded. 
Events are automatically time-stanq>ed by 
the trace logger. 

2. Receive Indicate event vfhen incoming data 
is indicated to the vpper layers. The source 
address, destmati<m address, source port and 
destination port ntmibers, the size of data 
received and the process Id of the Process 
that is being indicated by TCP. 

3. Receive Complete event (when a receive-Irp 
is completed with data). Similar infonnation 
is collected. 

These three trace points cover the majority of the 
meaningfiil TCP traffic in the system. It is 
important to keep in mind that some TCP traffic 
15 not accounted for by this instrumentation. For 
example, retransmissions from packet loss, 
receiving IP control msgs (like ICMP etc.). 

Instrumentation Overhead 

In comparison to other kernel events such as 
thread create or delete, oetwodc events are very 
high frequency events. As a result, extrsKxdinary 
care has been taken to minimize the overhead of 
trace instrumentation. The data being collected is 
primarily from die Transport Control Block 
(TCB) scntcture. Tbe fields in the TCB structure 
are arranged to make dw data relevant to 
c^>acity planning in cat ccmtiguous bbck. This 
allows direct cop^g fixHn die TCB structure to 
die Trace Buffers widiout having to make any 
intennediary copies. In our measurements, a 
network event uses about 128 xS6 mstructions 
and logs 24 bytes of data. 

Analysis of sample Traces 

A|^>endix A provides a sample kernel trace 
fragment from a TCn» Send test, translated into 
readable text fonnat £adi row in die table 
shows an event instance. Each event instance is 



described by the fixed header i»x>vidingthe evat 
name. Thread ID diat as causing the event 
system clock time \^ien die event happened, tte 
kernel and user mode CPU time for die thread 
Additional oolunms m die table show die evttf 
specific data associated with eadi event 

The tests were started after starting up die Trace 
logger using a command line utili^ called 
tracelog.exe. The trace shows die process sttit 
and end of the tracelog.exe. Next we see a 
process start for the TC? send test prognn 
(nttcp.exe). Immediately following that we see 
die Tcp Send events. We can see tbe source If 
address/port and destination IP address/p(»t. 

The size of transfm is 8K bytes. Hie thrad 
that's acmally performing die send b (duead M 
0» a syston thrrad). However* the process Id dot 
was saved i^ien the cconecdon was created is 
1C0» recorded widt every send event TMs 
process Id ICO anresponds to die Bttcp.cae 
program that initiated the sends. Hence, we cm 
see that the netwwk traffic can be charged ta 
processes properly frcun our traces. 

While the TCPSend events triggered en 
tbe nttcp connection were in progress, an HTI? 
request for a webpage happened (shown in 
italics) and through direadlD 39C, this reqoesi 
was handled by the US running on port 80 uidS 
files were sent out to die HTTP remote browsa. 
The HTTP transaction happened throi^ a keep- 
alive connecdqn. These events were charged to 
{ffocess 382 (Inetlnfo.exe). 



Possible uses of network traces 

Classification by PTDz 

In summary, since stack evem trace 
generated incorporates PID, it is possible to 
charge n^work traffic to a specific process or 
kernel mode service. We wOl i^esent odier 
possible modes of classification, such as per- 
service, per-NlC, per-rcmote-request v pcr- 
dient as indicated m paragraphs below. 

Classification of n^ork utilization per 
Service: 

From post-f rocessing the collected trace 
mformadon, it is possible to classify the 



bandwidth utilizatioD by application / service. 
Services and user applications / connections can 
be characterized using the 4-tuple (SAddr, 
DAddr, Sport, DpanX The traces collected for 
the specific port show the utilization for a 
particular service. From the traces shown, it csm 
be observed that (HTTP> web service active on 
port 80 can be chaa:ged for the receives and sends 
in italics. 

Classification of network utilization per NIC: 
Using tools such as IPConfig, it is 
possible to ideiUify NlCs and assigned IP 
addresses. Parsing the collected trace fcxr a 
specific IP Source Address gives all the traffic 
for that particular NIC It is possible that data 
rerouting can happen when a transfer is in 
progress. In such a case, TCP receives an 
indication and a special stack event trace is 
generated. 

Classifiaition of System resource ntilizatioo 
per remote request / client: 

Since Disk I/O events are generated in 
the context of &e process, and remote requests 
are charged to tiie same process (through stack 
event traces^ it is possible to ident^ the ninning 
service to charge disk i/o operattcms to. Based on 
Destination IP addr, this can be further classified 
per client of die service. 



Conclusion 

Widi the introduction of Event Tracing 
for Windows NT 5.0, we can charge resource 
consumption of CPU, Memory (Page feultsX 
Disk I/O and Network to appKcations (h- 
Services, This will make the task of capacity 
planning cUent/server plications ruamng cm 
Windows NT serms easier and more accurate. 

References 

1. Beyond BandwUhh—Maii^cutte Style 
Capacity Planning for Networks and 

If md!ow JP. Buzen and A. W. Slmm, 
Conference Proceedings CMC 96. 

2. Considerations for Modeiing Windows NT, 
J. P. Buzen and A. W. Shum, Conference 
Proceeedihgs CMG97. 

3. Ccpacity Planning for ffWows NT: EverU 
Tracing and Instrunmniation, Jee Fung 
Pang, CMG 97 Late Breaking Paper. 

4. Inside Windows NT (Second Echtiorf), Davkl 
Solomcm, Microsoft Press 1998. 

5. Networking in Microsoft Wintkws NT, Glen 
Clark, MSDN Technical Articles. 



O 1997 Microsoft Corporation. All rights reserved. Microsoft and Windows NT are either registered 
trademarks or trademarks of Microsoft Corporation in &c United States and/or other countries. Other 
product and company nan^ mentioned herein may be the trademarks of their respective owners. 



Appendix A: 



Event Name 



TTO Clock (ins> I Kt 



Ut ParentTD) 
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ProcessStart 



1C0 
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34C 



Tracelog.exe 



ThreadStart 
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10C 



ThreadEnd 
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IOC 
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14 



ProcessStart 
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1124572773 



36 



28 
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67 
288 
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CMD.exe 



ThreadStart 
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36 



28 



IOC 



ICO 



ThreadStart 
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1124572898 
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DestAddr 



Spiirt 
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5010 
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172.31.255.147 
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TcpSend 
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172.31.249.34 
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S31 
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172.31.249.34 



172.31.254.11 
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6437 
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Image Name 



ThreadEnd 



IOC 



1124573789 



IOC 



1C0 



PrpcessEnd I IOC [ 1124573789 | 1 
L^end: Kt - Kernel Mode Time 



ICO 
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Ut - User Mode CPU Time 
PID - Process ID 
TU) - ThreadlD 



Tlic following are the extended record felds for the respects 
^OProcessdait - new Process Id, its Parent's Process id 



•□Process cod - currert Process Id, its Parent's Process id. die image mcname that ft was nm^ 

ThreadStart -new thread Id, its Process Id 
•0 Thread end - current thread Id being tenninated, its Process Id, 

•0 I/O rea4 I/O write -The signature ofthedi^whOT the I/O operation was done, the transfer size. 
• 0 TCPScnd . Source Address, Destination Address, Source port. Destination port. Size, Processld 
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